README

关于数据库原理类的部分不在这个位置，可以去看《小林coding_图解系列》的读书笔记，那里有MySQL和Redis两个图解系列，都比较详细

调研相关

时间序列型

见 TimeSeries Datebase 笔记

关系型

Kimi GPT：

关系型数据库（RDBMS）是数据存储和检索的一种方式，它们以表格的形式组织数据，每个表格由行和列组成。常用的关系型数据库有以下几款：

1. MySQL：一种开源的SQL数据库，由瑞典的MySQL AB公司开发，后被甲骨文公司收购。MySQL支持多线程、多用户，并且非常快速，适合中小型网站使用。
2. SQLite：一个轻量级的、文件系统基础的数据库，通常用于移动应用和小型项目。
3. PostgreSQL：一个高度可扩展的开源数据库系统，以其先进的SQL特性和对并发控制的支持而闻名。
4. Oracle Database：由甲骨文公司开发，是一个功能强大的商业数据库系统，广泛应用于大型企业和复杂的应用场景。
5. SQL Server：由微软公司开发，是一个全面的数据库解决方案，提供广泛的数据管理功能，适用于各种规模的应用程序。
6. DB2：由IBM公司开发，是一个企业级的数据库系统，特别适用于大型企业和复杂的数据仓库应用。
7. Access：由微软公司开发，是一个桌面级的数据库系统，适用于小型企业和个人用户。
8. OceanBase：由阿里巴巴开发，是一个高性能的分布式关系型数据库，适用于大规模数据存储和处理。
9. GaussDB：由华为开发，是一个企业级的数据库解决方案，提供高性能、高可用性和高安全性。
10. TDSQL：由腾讯开发，是一个云原生的数据库服务，提供高可用性和弹性伸缩能力。

这些数据库系统各有其特点和优势，选择哪个数据库系统通常取决于具体的应用需求、性能要求、预算以及对特定技术的熟悉程度。例如，MySQL和PostgreSQL因其开源特性和灵活性在许多Web应用中非常流行，而Oracle和SQL Server则因其强大的功能和企业级特性在大型企业中得到广泛应用。SQLite因其轻量级和易于嵌入特性，在移动应用开发中非常受欢迎。

非关系型

Kimi GPT：

非关系型数据库（NoSQL）是相对于传统的关系型数据库（RDBMS）而言的，它们不使用传统的SQL作为查询语言，并且不保证关系数据的ACID特性。非关系型数据库通常用于处理大规模数据集，提供高可用性和可扩展性，以及支持灵活的数据模型。以下是一些常用的非关系型数据库：

1. MongoDB：一个基于文档的数据库，以其高性能和易用性而闻名。MongoDB支持丰富的查询语言，允许嵌套的文档结构，非常适合处理复杂的数据结构。
2. Redis：一个高性能的键值存储系统，常用作数据库、缓存和消息中间件。Redis支持多种类型的数据结构，如字符串、散列、列表、集合、有序集合等。
3. Cassandra：一个分布式的键值存储系统，设计用于处理大量数据跨多个数据中心和服务器。Cassandra提供高可用性和可扩展性，适合需要高写入和读取速度的应用。
4. Couchbase：提供高性能和易扩展的文档数据库解决方案，支持JSON文档存储，并且具有强大的查询引擎。
5. Riak：一个分布式的键值存储数据库，以其高可用性和容错能力而著称。Riak设计用于分布式系统，提供快速的数据访问和良好的扩展性。
6. Neo4j：一个图形数据库，专门用于存储和查询包含复杂关系的数据。Neo4j使用图数据模型，非常适合社交网络分析、推荐系统等应用。
7. Amazon DynamoDB：一个完全托管的NoSQL数据库服务，提供快速和灵活的键值存储以及在任何规模的数据上进行的无缝索引入。
8. Apache HBase：是一个开源的非关系型分布式数据库（NoSQL），它运行在Hadoop的HDFS之上，用于存储和访问大规模的稀疏数据集。
9. CouchDB：一个使用JSON来存储数据的面向文档的数据库，使用HTTP和JavaScript（通过MapReduce）进行数据的复制和处理。
10. Elasticsearch：一个基于Lucene的搜索引擎，提供全文搜索的功能，并且可以用于分析复杂的数据集。

非关系型数据库的选择通常取决于具体的应用场景，例如数据的结构、读写需求、可扩展性、一致性要求等。每种数据库都有其特定的优势和适用场景，例如MongoDB适合处理文档数据，Cassandra适合需要高吞吐量写入的应用，而Redis适合用作缓存或消息队列。

• MongoDB（文档型）
• Cassandra（列族型）
• Redis（键值对型）
• Neo4j（图形数据库）

其他

ACID

ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：

• 原子性（Atomicity，或称不可分割性）
• 一致性（Consistency）
• 隔离性（Isolation，又称独立性）
• 持久性（Durability）

先引：性能指标

在比较性能之前，肯定先要说下性能指标。

参考：

• 主要参考、转载：一文搞懂高并发性能指标：QPS、TPS、RT、吞吐量
• 参考2：QPS、TPS、RT、吞吐量等高性能指标(一文秒懂)

QPS (Queries Per Second，每秒查询)

QPS：Queries Per Second 的缩写，意为 每秒查询率

是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

互联网中，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

TPS (Transactions Per Second，每秒事务)

TPS：Transactions Per Second 的缩写，意为 每秒事务，单位 事务数/秒

它是软件测试结果的测量单位。

事务

一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

QPS vs TPS

QPS 基本类似于 TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。

例如：访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。

如何减少事务、事务优化

参考：mysql 大事务优化

以 mysql 为例：

MySQL 大事务优化的主要思路是将一个大事务拆分成多个小事务，以减少事务持有锁的时间，避免锁冲突，提高并发能力。以下是具体的优化策略：

1. 提高事务隔离级别：将隔离级别设置为 READ COMMITTED 或更高级别，可以避免脏读和不可重复读等问题，但会增加锁竞争，需要进行优化。
2. 减少事务的执行时间：通过减少事务的操作数量和复杂度，减少事务的执行时间。可以使用批量操作、分批次提交等方式来减少单次事务的操作数量。
3. 分离大事务：将大事务分解成多个小事务，减少单个事务持有锁的时间。例如，可以使用分片技术将数据分散到多个库或表中，将单个大事务分解成多个小事务。
4. 使用较短的事务：如果单个事务无法分解成多个小事务，可以尽量缩短事务的执行时间。例如，在更新大量数据时，可以使用 limit 子句将数据分成多次更新，每次更新一小部分数据。
5. 使用批量提交：将多个事务合并成一个事务，并使用批量提交技术来执行，可以减少事务的执行时间，并提高并发能力。
6. 调整 InnoDB 相关参数：例如，将 innodb_buffer_pool_size 调整到合适的大小，可以减少磁盘 IO 操作，提高性能。

以上是针对 MySQL 大事务优化的一些常用方法和思路，具体的优化策略需要根据具体业务场景和数据规模进行分析和优化。

具体的：

RT (Response-time，响应时间）

RT：Response-time 的缩写，意为 响应时间

响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。

是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。

并发数

并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。

吞吐量

系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。

1. QPS（TPS）：（Query Per Second）每秒钟request/事务 数量
2. 并发数： 系统同时处理的request/事务数
3. 响应时间： 一般取平均响应时间

理解了上面三个要素的意义之后，就能推算出它们之间的关系：

$$QPS~(TPS)= \text{并发数}/\text{平均响应时间}\\ ~~~~~~~~~~~~~并发数 = QPS\times\text{平均响应时间}$$

总结 - 实际举例

二八定律的峰值问题

我们通过一个实例来把上面几个概念串起来理解。按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。

• 公式：$( 总PV数 * 80\% ) / ( 每天秒数 * 20\% ) = 峰值时间每秒请求数(QPS)$
• 机器：$峰值时间每秒QPS / 单台机器的QPS = 需要的机器$

题目举例

1、每天300w PV 的在单台机器上，这台机器需要多少QPS？

$( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)$

2、如果一台机器的QPS是58，需要几台机器来支持？

$139 / 58 = 3$

总结 - 最佳线程数、QPS、RT

单线程QPS公式：QPS=1000ms/RT

对同一个系统而言，支持的线程数越多，QPS越高。假设一个RT是80ms,则可以很容易的计算出QPS,QPS = 1000/80 = 12.5 多线程场景，如果把服务端的线程数提升到2，那么整个系统的QPS则为 2*（1000/80） = 25, 可见QPS随着线程的增加而线性增长，那QPS上不去就加线程呗，听起来很有道理，公司也说的通，但是往往现实并非如此。

QPS和RT的真实关系

我们想象的QPS、RT关系如下，

图）

实际的QPS、RT关系如下，

图）

最佳线程数量

刚好消耗完服务器的瓶颈资源的临界线程数，公式如下 最佳线程数量=（（线程等待时间+线程cpu时间）/线程cpu时间）* cpu数量 特性：

• 在达到最佳线程数的时候，线程数量继续递增，则QPS不变，而响应时间变长，持续递增线程数量，则QPS开始下降。
• 每个系统都有其最佳线程数量，但是不同状态下，最佳线程数量是会变化的。
• 瓶颈资源可以是CPU,可以是内存，可以是锁资源，IO资源：超过最佳线程数-导致资源的竞争，超过最佳线程数-响应时间递增。